Investment accounts hold stocks, bonds, mutual funds, and the like for individuals, trusts, corporations, and other investors. Investors typically utilize such accounts to achieve long and short term savings goals. The holdings of an investment account may be manipulated by the investor, such as by an investor executing securities purchases or sales via a graphical user interface and an Internet connection. An investor can be any of a number of different types of entities, including an individual or a business. The holdings of an investment account may also be manipulated by an entity managing or otherwise associated with the investment account, such as a money manager, a brokerage firm (sometimes referred to as a broker-dealer or a sponsor), or some other type of investment firm.
Conventional investment management systems store security attributes and associated authority data values in a central data file, referenced herein as a central security master. The data values for various attributes for a security can be stored in separate data fields in a single record within the central security master. Examples of typical attributes that may be stored include company name, stock ticker symbol, share price, sector, and/or industry code. Illustrative examples of data values associated with those attributes are “CheckFree” (company name), “CKFR” (stock ticker symbol), “$45.25” (share price), Financial (Sector) and “Fin” (Industry Code). It will be appreciated that the illustrative examples of attributes are not limiting, as the attributes can be anything defined by the money manager or any other individual operating the system.
As an illustrative example, a central security master containing nine (9) securities is shown as follows, with attributes including company name, stock ticker symbol, share price, and sector:
TABLE 1Illustrative Central Security MasterCompany NameTickerShare PriceSectorCheckFreeCKFR$36.95FinancialCorillianCORI $3.16FinancialFirst DataFDC$41.94FinancialHewlett-PackardHPQ$26.72TechnologyIBMIBM$81.32TechnologyIntelINTC$25.53TechnologySBCSBC$23.91TelecommunicationsSprint NextelS$25.96TelecommunicationsVerizonVZ$32.79Telecommunications
Using a central security master a client of the investment management system, a user entity such as a money manager or broker-dealer, may create a client-specific security file. This may be accomplished via a graphical user interface or the like that permits the selection of a subset of the securities stored in the central security master. Like the central security master, a client-specific security file may be stored within the memory of the investment management system or accessed thereby. The client-specific security file includes a subset of securities needed to manage the user's particular portfolio(s). As an example, a money manager may create a client-specific security file from the central security master shown in Table 1 as follows:
TABLE 2Illustrative Client-Specific Security FileCompany NameTickerShare PriceSectorCheckFreeCKFR$36.95FinancialFirst DataFDC$41.94FinancialIBMIBM$81.32TechnologyIntelINTC$25.53TechnologySBCSBC$23.91TelecommunicationsVerizonVZ$32.79Telecommunications
After creation of the client-specific security file, a user may wish to generate additional records for securities of interest that were not found in the central security master. This may be accomplished via one or more GUIs, as are known in the art. These additional securities may include securities the user wants to track as actual or potential investments or any other securities of interest to the user. For example, a user may add securities to extend the illustrative client-specific security file of Table 2 to include Cisco and Microsoft securities, as is shown in the revised client-specific security file of Table 3. The data values located in the data fields for the new security records are illustrated in bold.
TABLE 3Illustrative Revised Client-Specific Security FileCompany NameTickerShare PriceSectorCheckFreeCKFR$36.95FinancialCiscoCSCO$17.52TechnologyFirst DataFDC$41.94FinancialIBMIBM$81.32TechnologyIntelINTC$25.53TechnologyMicrosoftMSFT$26.81TechnologySBCSBC$23.91TelecommunicationsVerizonVZ$32.79Telecommunications
The user may also wish to include additional attributes for particular securities. This may beneficially provide variability in account management, reporting functions, executing transactions, and the like. For example, where a user adds a second price attribute, such as the “Share Price 2” as is shown in Table 4 below, the first share data value may represent a discounted purchase price (as with an employee stock purchase plan) and the second share data value may represent a fair market value purchase price. Also illustrated in Table 4 is a “Sector 2” attribute added by the user.
TABLE 4Illustrative Client-Specific SecurityFile with Client-Added AttributesCompanyShareShareNameTickerPricePrice 2Sector 1Sector 2CheckFreeCKFR$36.95FinancialCiscoCSCO$17.52TechnologyTechnology &CommunicationsFirst DataFDC$41.94$41.10FinancialIBMIBM$81.32$79.69TechnologyIntelINTC$25.53TechnologyMicrosoftMSFT$26.81$26.27TechnologySBCSBC$23.91Telecommu-Technology &nicationsCommunicationsVerizonVZ$32.79Telecommu-Technology &nicationsCommunications
To handle the use of multiple potentially conflicting data values for similar attributes, conventional systems require the creation of a group definition file that defines which accounts constitute a particular group. These groups may be defined explicitly (i.e., as a list of one or more accounts) or via some rule that can dynamically determine whether a given account belongs to the group. A new group definition file would have to be created for each distinct group. The portfolio management system would then have to reference each group when performing various tasks, such as executing trades, generating reports, analyzing account performance, and the like, and explicitly override the use of a “default” security master value. As an illustrative example, a portfolio management system may contain a hard-coded software modification that, for a particular account grouping, the “Share Price 2” data value (rather than the “Share Price” data value) should be used to execute a buy, such as a buy limit order. Portfolio management functionality that could contain such customizations includes account rebalancing, various future projection and proposal generation tools, restrictions processing, reconciliation, performance analysis, and reporting.
One problem with such conventional systems to client-specific security file customization is that it requires the construction and correlation of two separate data sources—the client-specific security file and the one or more group definition files. Another problem is that the portfolio management system software must be modified for each desired alternative operation for each account grouping. Over time, the number of group definitions and software customizations may explode, adding to system complexity. Additionally, having to hard-code each alternate operation is prone to error (it may be easy to overlook an associated function that should be changed at the same time), presents implementation delay, and is inherently inefficient from a cost/effort perspective.
What is needed are systems and methods that permit users to define investment account attributes and the automatic assembly and use of different attribute values without requiring the use of one or more separate group definition files and associated hard-coded software customizations.